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-Sharing  CPU  -  Round  robin 


Same  time  requirement  -  Fair  Scheduling 
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Planning 


Consolidation  of  Mixed-Criticality  Tasks 


Shared  Hardware 
Can  lead  to  cycle  stealing 
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Planning 


Consolidation  of  Mixed-Criticality  Tasks 


To  avoid  interference 
add  temporal  protection 
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Planning 


Consolidation  of  Mixed-Criticality  Tasks 
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Criticality  Inversion 


A  higher-criticality  task  waits  for  a  lower-criticality  task  to  release  a 
resource 

•  Symmetric  temporal  protection 

•  Scheduling  policy  is  aimed  at  maximizing  utilization  (RMS/DMS/EDF) 
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Rate-Monotonic  Priority 


Shorter  Period  ->  Higher  Priority 

•  Ideal  utilization 

BUT:  Poor  Criticality  Protection  Due  to  Criticality  Inversion 

•  If  criticality  order  is  opposite  to  rate-monotonic  priority  order 
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Criticality  As  Priority  Assignment  (CAPA) 


Higher  Criticality  ->  Higher  Priority 

•  Ideal  criticality  protection: 

-  lower  criticality  cannot  interfere  with  higher  criticality 
BUT:  Poor  Utilization  Due  to  Priority  Inversion 

•  If  criticality  order  is  opposite  to  rate-monotonic  priority  order 
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Task  Model 
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Zero-Slack  Scheduling 


Start  with  RM 

Calculate  the  last  instant  before  thc  misses  its  deadline 

•  this  is  called  the  zero-slack  instant 

Switch  to  criticality-as-priority 

•  Splits  the  execution  window  into 

-  Normal  mode  (RM) 

-  Critical  mode  (CAPA) 


xLC  =(2,2, 4, 4) 
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Critical  Instant  of  a  Task  tj 
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Interference  in  Zero-Slack  Scheduling 


Task  Set  Divided  into 

•  Hlc :  Higher  priority,  lower  criticality 

•  Hhc :  Higher  priority,  higher  criticality 

•  Llc :  Lower  priority,  lower  criticality 

•  Lhc :  Lower  priority,  higher  criticality 
Interfering  tasks  in  normal  mode  (Normal  mode) 

•  Hlc  +  Hhc  +  Lhc 

Interfering  tasks  in  critical  mode  (C  mode) 

•  Hhc  +  Lhc 
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Scheduling  Guarantee 


A  task  T- is  guaranteed  C° before  D 

l  l  l 

if  no  Tj  I  <  £ 
executes  beyond  its  C . 
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Calculating  The  Zero-Slack  Instant 


\ 


Start  of  trailing 
slack 


Slack  Normal  Mode  Slack  Critical  Mode 


===-  Software  Engineering  Institute  CarnegieMellon 


Temporal  Protection  RT  Systems 
de  Niz,  November  2016 

©2016  Carnegie  Mellon  University 


[Distribution  Statement  A]  This  material  has  been  approved  for  public  release  and  unlimited  distribution.  Please  see  Copyright  notice  for  non-US  Government  use  and  distribution. 


16 


Calculating  The  Zero-Slack  Instant 


New  slack  can  open  after  each  iteration 
Needs  to  repeat  until  no  new  slack  opens 
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ZSRM  Properties 


Subsumes  RM 

•  If  criticalities  are  aligned  to  priorities 

•  No  critical  mode 

Subsumes  CAPA 

•  If  not  enough  slack,  only  critical  mode 

Graceful  Degradation 

•  In  overloads,  deadlines  are  missed  in  reverse  criticality  order 
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Implementation 


ZSRM 

Scheduling  algorithm  calculates  zero-slack  instants  offline 
Linux/  RK 

•  Resource  reservation  in  Linux 

-CPU,  Net,  Mem,  Disk 

•  Bundled  into  resource  sets  that  provide  a  form  of  virtual  machine 

•  Multiple  implementations 

-  Nano/RK  for  sensor  networks 
Special  Zero-Slack  Reserves 

•  Switch  to  critical  mode 

-  Stop  lower-criticality  tasks  on  zero-slack  instant 

•  Tasks  in  critical  mode  in  stack 
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Planning 


What  about  Shared  Resources? 


•  Consider  a  new  medium  priority  and 
Medium  criticality  task  (say  v2v  task) 


Let  Planning  and  Obstacle  Avoidance  share 
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Priority  and  Criticality  Inversion 
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Blocking  in  Zero-Slack  Scheduling 


A  job  Jh  waiting  for  a  job  to  exit  critical  section  Zlk  is  considered 
to  be  blocked  at  time  t,  if  and  only  if  one  of  the  following  conditions 
is  satisfied  at  t: 


1 )  The  priority  of  J,  is  lower  than  J^s  priority  and  Js  is  running  in  its 
normal  mode. 


2)  The  criticality  of  J,  is  lower  than  J^'s  criticality  and  Jh  is  running 
in  its  critical  mode. 
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Priority  and  Criticality 
Inheritance  Protocol  (PCIP) 
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PCIP  Definition 


A  task  Tj  that  holds  a  lock  to  a  resource  can  inherit  the 
priority  from  a  task  x,  and  the  criticality  from  a  task  xk  (xk 
can  be  the  same  as  xi ),  both  requesting  a  lock  to  the 
resource  held  by  x,  as  follows: 


Tj  inherits  the  priority  of  Tj  if  Tj ’s  priority  is  higher. 

-  This  inherited  priority  has  an  immediate  effect  on  the  scheduling  of  T; 


Tj  inherits  the  criticality  of  T^  if  T^’s  criticality  is  higher. 


-  This  criticality  is  used  by  Tj  immediately  as  soon  as  T^  requests  the 
lock  held  by  Tj 
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PCIP  Possible  Blocking 


Consider  a  Job  J, 


I 


.  L^fJg)  is  the  set  of  jobs  with 


lower  priority  and,  higher  criticality  Je 

U  (fyoS 


.  LffJg)  is  the  set  of  jobs  with 
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PCIP  Properties 


.  Under  PCIP,  given  a  job  iV0for  which  there  are  n  jobs  {JVJ2 

with  J(.  in  {  Lihc(j0)ULilc(j0)UHilo(j0)},  job  J0  can  be  blocked 
for  at  most  the  duration  of  one  critical  section  in  each  of  |3*0  r 

-  where, 

p*0 1  is  the  set  of  critical  sections  of  J- that  can  block  J0 


*  Under  PCIP,  if  there  are  “m”  locks  which  can  block  job  J,  then  J 
can  be  blocked  at  most  “m”  times  in  its  normal  mode  and 
blocked  at  most  “m”  times  in  its  critical  mode. 
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PCIP  Illustration 
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Priority  and  Criticality 
Ceiling  Protocol  (PCCP) 
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PCCP  Definition 


.  Each  lock  is  assigned  both  a  priority  ceiling  and  a 
criticality  ceiling 

-  Priority  ceiling  is  the  highest  possible  priority  of  any  locker  of 

the  lock 

-  Criticality  ceiling  is  the  highest  possible  criticality  of  any  locker 

of  the  lock 

.  Both  the  priority  ceiling  and  the  criticality  ceiling  of  a 
lock  are  acquired  by  task  whenever  it  holds  the  lock 
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PCCP  -  Maximum  Blocking 


.  Each  job  Jean  only  be  blocked  twice 

-  At  most  once  in  Normal  execution  mode 

-  At  most  once  in  Critical  execution  mode 

.  Each  job  Jw  can  block  job  J  only  once 

-  Otherwise,  Jw\ s  L/C(J^ 

-  And,  Job  Jhas  to  be  blocked  by  J^once  in  Normal  mode 

-  However,  Jw  cannot  obtain  the  processor  again  as  it  is  in  L/c(Jg) !!! 
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PCCP  -  No  Deadlocks 


.  Under  PCCP,  no  job  Jk  can  preempt  another  job  J,  while  Jj  holds  a 
lock  (i.e.  is  inside  the  critical  section)  that  is  also  accessed  by  Jk. 

.  PCCP  prevents  Transitive  Blocking 

.  PCCP  prevents  Deadlocks 
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PCCP  Illustration 


Task  t0  acquires  the  Priority  and  Criticality  Ceiling  of 
Task  x1  acquires  thhc&ricc(ffl;y  tffld  Criticality  Ceiling  of 
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PCIP  Blocking  Term  Analysis 


.  PCIP  Blocking  Term  6,-f or  Task  Xj 

Bi  =  min(  £  Wj).  I]  2A(*iifc)) 

,  r,e{H‘cULicUtfc}  **.»£** 

where, 

o  p*: :  is  the  set  of  critical  sections  of  x,  that  can  block  x, 

J  1 

o  A,(P*  J  is  the  length  of  the  longest  critical  sections  of  p* ,  that  can 
block  task  x, 

o  A(4/i ,)  is  the  length  of  the  critical  section  protected  by  lock 'Fjj 


Software  Engineering  Institute  Camegfe  Mellon 


Temporal  Protection  RT  Systems 
de  Niz,  November  2016 

©2016  Carnegie  Mellon  University 


[Distribution  Statement  A]  This  material  has  been  approved  for  public  release  and  unlimited  distribution.  Please  see  Copyright  notice  for  non-US  Government  use  and  distribution. 


33 


PCCP  Blocking  Term  Analysis 


PCCP  Blocking  Term  B;  for  Task  Xj 


where, 


Bi  =  max  2A(l?*  •) 

Tj€{lfieULj0ULfn}- 


p*  j  is  the  set  of  critical  sections  of  x,  that  can  block  task  x= 

h\  J  1 

A,(p*|j)  is  the  length  of  the  longest  critical  sections  of  p^ ,  that 
can  block  task  x; 
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Criticality  isolation  strategy  (S) 


Low  Criticality 
High  Criticality 


Processor  1 


Processor  2 


Both  overload 
High  criticality  overload 
Low  criticality  overload 
No  overload 


H 

0 

0 

1 

1 


L 

0 

1 

0 

1 


Assume  that  the  system 
is  schedulable  without  overloads 

Under  overloads  only  one 
task  can  meet  its  deadline 
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Criticality  mixture  strategy  (T) 


Low  Criticality 
High  Criticality 


Processor 

H 


Both  overload 
High  criticality  overload 
Low  criticality  overload 
No  overload 


1 

1 

1 

1 


1 


V 


L 

0 

0 

0 
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T  is  better  than  S 


Processor  2 

Assume  that  the  system 
isschedulablewithout  overloads 
Under  overloads  only  one 
task  can  meet  its  deadline 
Assume  that  a  uniprocessor 
mixed-criticality  scheduling  algorithm 
like  ZSRM  is  used  within  each  processor 
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Generalization:  Ductility  Matrix 


< -  Criticality 


Say  we  have  'k'  criticality  levels 
2k  possible  overload  scenarios 

'  All  criticality  levels  overload  to  No  overload 
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Quantification  of  Ductility 


(D)  =  I?=i 


Scheme  S 

H  L 

r  ~\ 

Scheme  T 

H  L 

r  "\ 

Both  overload 

0  0 

Both  overload 

1  0 

High  criticality  overload 

0  1 

High  criticality  overload 

1  0 

Low  criticality  overload 

1  0 

Low  criticality  overload 

1  0 

No  overload 

1  1 J 

No  overload 

_ j 

ForS,  Pd  (D)  =  0.375  For  T,  Pd  (D)  =  0.5625 

Shows  that  T  is  better  than  S 
Other  Projection  functions  can  be  used 

Pd(D)  favors  the  more  critical  tasks  exponentially  over  the  lower  criticality  tasks 
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Outline 


Mixed-criticality  task  scheduling  problem 
Zero-slack  scheduling  for  uni-processors 

•  Zero-slack  metrics  &  properties 

Generalizing  resource  allocation  to  distributed  mixed  criticality  tasks 

•  Generalized  metric:  Ductility  matrix 

Compress-on-Overload  Packing  (COP) 

•  COP  Performance 

Radar  surveillance  case  study 
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Less  critical  More  critical 


Compress-on-Overload  Packing  (COP) 
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Less  critical  More  critical 


Compress-on-Overload  Packing  (COP) 


1 

B 

1 

B 

1 

B 

1 

B 
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B 
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B 
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B 

B 

Phase  1 :  Pack  by  criticality  then  size 

object  size  = 


.  Software  Engineering  Institute  CarnegieMellon 


Temporal  Protection  RT  Systems 
de  Niz,  November  2016 

©2016  Carnegie  Mellon  University 


[Distribution  Statement  A]  This  material  has  been  approved  for  public  release  and  unlimited  distribution.  Please  see  Copyright  notice  for  non-US  Government  use  and  distribution. 


41 


Less  critical  More  critical 


Compress-on-Overload  Packing  (COP) 


Phase  2:  Pack  by  criticality  then  size 

object  size  = 


B 
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Less  critical  More  critical 


Compress-on-Overload  Packing  (COP) 


Phase  2:  Pack  by  criticality  then  size 

object  size  = 


B 

B 


=  Software  Engineering  Institute  CarnegieMellon 


Temporal  Protection  RT  Systems 
de  Niz,  November  2016 

©2016  Carnegie  Mellon  University 


[Distribution  Statement  A]  This  material  has  been  approved  for  public  release  and  unlimited  distribution.  Please  see  Copyright  notice  for  non-US  Government  use  and  distribution. 


43 


COP  Performance 


-♦-COF(ITD) 

-»-OOP(BFD) 

-*-OOP(WFD) 

-W-WFD 
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Overloading  in  Mixed-Criticality  Systems 


Task 

Period 

Criticality 

WCET 

NCET 

Surveillance  Cov. 
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t2  Collision  Avoid. 
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Safety 
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t2 


4  8 
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Zero-Slack  Rate  Monotonic 


Task 

Period 

Criticality 

WCET 

NCET 

Surveillance  Cov. 
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Mission 
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2 

t2  Collision  Avoid. 

8 

Safety 

5 

2.5 

i  = 

1 

1 

i 

L^ 

Zero-Slack  Instant 
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Zero-Slack  Rate  Monotonic 


Task 

Period 

Criticality 

WCET 

NCET 

t1  Surveillance  Cov. 
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Mission 
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2 

t2  Collision  Avoid. 
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Safety 
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Reclaiming  Resources  in  Mixed-Criticality 
Systems 


Task 

Period 

Criticality 

WCET 

NCET 

Utility 

t1  Surveillance  Cov. 
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t3  Amount  of  Intelligence 
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2 

{2,2.5} 
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Using  Reclaimed  Resources  to  Maximized 
Utility 


Task 

Period 

Criticality 

WCET 

NCET 

Utility 

Levels 
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Software  Ei  Utility  Diminishes:  Utility  t  Criticality  action  RT  Systems 
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Using  Reclaimed  Resources  to  Maximized 
Utility 


Task 

Period 

Criticality 

WCET 

NCET 

Utility 

Levels 

^  Surveillance  Cov. 
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Mission 
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2 

{2,2.5} 

t2  Collision  Avoid. 
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Safety 
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2.5 

t3  Amount  of  Intelligence 
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{2,2.5} 

1  2 


1  1 
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ZS-QRAM:  More  mission-critical  utility  from  same  resources 
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